DPRS / SAE 2 avenue

In this extended abstract we present a methodology that able us to validate/invalidate the System Requirements Document. The approach we suggest is not a brand new one. Nevertheless because it combines semi formal and formal notations, it allows overcoming the traditional formal specification phase, which is very often mandatory for the development of software intensive system. Our paper is organised as follows. It introduces the context in which such a methodology can be used, it then describes the methodology itself, and finally it instantiates it on an example that has been considered, from an industrial point of view, only according to a formal point of view. The context We consider Software Intensive Systems (SIS), i.e. systems for which the Software is safety critical. In other words, an SIS is a system whose reliability depends directly on its embedded software. These systems are numerous in the industrial world. The example we have chosen for this extended abstract is borrowed from telephone systems, where the discovery of services interaction is mandatory before its first use. Indeed the liberalisation of telephone services has reached a so high level that the integration of new services can introduce inconsistency between them. Discovering inconsistencies, so called services interaction, before the integration of any new service is an important point that should be solved during the upper phases of their development, mainly during the specification phase. Some methodology as the one introduced in [1] exists. Unfortunately they use dedicated formal techniques that are heavy and totally disconnected from the rest of the traditional industrial development. Our methodology Our methodology is based on overcoming the above statement that is: how to integrate a formal specification phase harmoniously into a traditional system life cycle. For that purpose we have re-considered the specification phase. Industry and labs consider the specification phase in total different ways. For industry, a specification is an informal description of what the system should do, whereas for labs a specification is a formal description of the system properties. A decade ago the arrival of semi formal notations such as UML [2] has not bridge the gap between the 2 different points of view, though some formal notation has been added, such as OCL [3] for instance. Our methodology takes advantage of semi formal notations, integrates a formal notation in a consistent fashion, and above all, suggests a method, i.e. a rigorous sequence of steps for designing semi formal and formal models. Step 1: validation/invalidation of the System Requirement Document (SRD) The first step is dedicated to a semi formal specification of the system under consideration. As usual the 1 step gives rise to the validation/invalidation of the System Requirement Document, the most important by-product. Unfortunately because we recommend using semi formal notations such as UML, the validation that can be given by the end users team cannot be trusted. Traditional cross readings/inspections are not sufficient to guarantee the validity of a semi formal description. Many misinterpretations can subsist, without being discovered by a deep inspection. This is the reason why we suggest complementing the semi formal specification (mainly a large class diagram) by a set of formal specifications. We use of Z [4] instead OCL because Z offers both very rigorous notations, and a methodology for guaranteeing some properties of the system under consideration. Satisfiability, consistency and robustness are the most important from an industrial point of view. Complementing the semi formal specification by a formal one expressed in Z is a very heavy task that is fortunately facilitated by a set of semi automated translation rules we have exhibited in [5]. The result of such a formal specification is more an invalidation than a validation. Indeed, giving semantics to operations may reveal some deficiency of the semi formal model. In the same way as an implementation may invalidate an algorithm, a formal specification may invalidate a semi formal one. Our experiments have shown [6] that the main deficiency comes from either an incomplete, or ambiguous, or contradictory informal specification. Moving to a Z formal specification may give rise to interpretations that may be wrong. More often, the formal semantics is either impossible, or so complex that it reveals a deep error. It does not seem we are able to establish an exhaustive list of all the reasons why a semi formal specification raises a wrong formal one. A second reason for invalidation of the semi formal model is the use of the Z method. As soon as a formal specification of an operation has been set up, it is necessary to proof that it is consistent with the system invariants/properties. This step may reveal that the semi formal specification is inconsistent, from the system point of view. As claimed above, the 1 step is more an invalidation than a validation. Nevertheless, the work done during this step is pertinent because it obliges the specifier to better understand what the system is. Step 2: building a stable and consistent kernel The 2 step of our methodology consists in re-specifying the system, but in a quite different way. We apply the methodology we suggested a long time ago. The starting idea is the setting up of a stable kernel, i.e. a system whose main functions should not evolve, and to demonstrate that it is consistent from a Z point of view. Of course we take advantage of the 1 step in order to design the kernel. From a practical point of view we have noticed that independent concurrent kernels may exists. Indeed, for large applications, parts of the final system are semi independent. Our methodology takes this into account in allowing different kernels to co-exist independently. The consequence of building a semi formal kernel complemented by a formal one as above is that after a few short iterations we can guarantee a stable and consistent kernel. It is consistent due to the formal used notations. It is stable because agreed by the end user team. It must be noticed that every time a formal Z specification is produced we need translate it into some natural text in order to make it understandable by the end user team. On the other end there is no difficulty at all to make the semi formal model readable by the end users team. Step 3: building consistent increments The 3 step of our methodology consists in building/specifying the whole system as a result of small increments. This sub process is itself divided in 3 sub steps. The 1 one is the update of the semi formal model of the kernel with new elements such as a class, some new attributes, and a few new operations. The increment should be small enough that any later inconsistency discovery should not give rise to a too difficult decrement. The 2 one is relative to its formal specification in Z. The 3 one is concerned with its validation. We applied as above the Z methodology: consistency and robustness are the 2 main ones. In case of discovery of any inconsistency it is mandatory to decrement the semi formal model, i.e. to erase the just added elements, and to rebuild a new increment. In case of lack of robustness, it is mandatory to add some new elements to the semi formal model, those ones that have been identified by the robustness sub step. Consequently the global specification of the systems evolves in an incremental manner according to 2 complementary points of view: the semi formal one and the formal one. Step 4: delivery of the final SRD The building of increments is stopped as soon as a complete specification has been reached. By complete we mean a semi formal specification and a formal one that are compliant with the original Requirements Document, as written by the end users team at the very beginning of the development. The produced specifications should be considered as an important by-product from which the development can start. Nevertheless these specifications are in no way a reference document. It must be remembered that industry does use SRD, which are mainly structured according to some standard, but are informal documents. A direct consequence is that we need translating both semi formal model and formal one into natural texts. This work is a first importance because the end users team will validate it! Application: telephone services integration In the area of telephony systems, more and more services are offered. A main question is to be able to detect a service interaction before any service is integrated into an existing telephone network. Our example considers a very simple switching system, based on a Basic Call Services (BCS) machine. This machine includes both hardware and software. It offers basic features such as connecting/removing telephone lines, dialling, an electronic phone book, communication costs, etc. On the other hand we consider 2 new services that should be integrated in the BCS: CFU (Call Forward Unconditional) – all calls to a subscriber must be forwarded to another number TCS (Terminal Call Screening) – the user is not allowed to be connected to other subscribers from a given list (black list), in any case (even if the original call is forwarded). In our presentation we will emphasize the way we have specify the integration of service such as CFU and TCS, and show how the service interaction has been detected. Step 1: validation of the SRD Following our methodology we have first of all designed a semi formal model of the BCS. The BCS is representative of an existing switching system. Specifying what does exist is accurate because it reduces the work of specifying the end users’ needs. Indeed end users’ needs may be very often considered as extension of existing functions that are implemented in some system. In our example the BCS is both an existing system and a system in which new needs should be integrated. It must be noticed that the difference between a 1 specification (what the system does) and a 1 design (how it does it) is very short. Nonetheless we have applied our methodology. We skipped the 1 step because the BCS being an existing system we took it as our kernel. Step 2: building a stable and consistent kernel We built the semi formal model of the BCS according to the OO approach. We then translated it into some Z specification (including different state spaces and numerous schemas operations). Because the system was critical enough, we have been able to identify many invariants. The formal validation phase, i.e. the proof that invariants are preserved by the operations, gave rise to a few updates of the semi formal model. Step 3: building consistent increments Sub step 3.1: specifying FCU The first increment we designed was that one concerned with CFU. From a semi formal model point of view, designing CFU is just creating a new reflexive association between phones. Its translation in Z was easy, the adding of a new relation, and an update of the dial operation. This increment was validated both from a formal and a semi formal point. There was no detected interaction between CFU and existing services offered by BCS. Sub step 3.2: specifying TCS The TCS specification was, as for CFU, very easy. We introduced the notion of black list as a set of phones. And, as for CFU, we formally specified the black list as a variable in the main state space, and accordingly we updated the dial operation, giving it the semantics of a black list. Its formal and semi formal validation was reached as well. We didn’t discover any interaction. Indeed the dial updated operation took into account the originator of the call. If the call belongs to the black list, then it is not accepted, otherwise it is. It clear that after a CFU, we are just considering who is calling, not any forward call. We then discovered that the Requirement Document was not precise enough: interaction was not clearly described! Thus we re-specified the main invariants in another way. Instead of making them depending on the state space where the black list was designed, we push them into the BCS itself. Eventually when respecifying we discovered an interaction when a CFU is used before a TCS, and of course when the 1 call belongs to the black list to which the call is forwarded.